Games of Daze/Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso/x2ftp/msdos/biz/macmyths.txt

Internet Message Format | 1995-03-25 | 10KB

From: [e-mail] (Lawson English)
Newsgroups: rec.games.programmer
Subject: Mac Mythconceptions (Was Re: Why Mac not a games platform)
Date: 17 Mar 1995 16:36:39 GMT


What follows is possibly the best example that I have ever seen of the
misconceptions about the Mac that exist in the DOS/Windows/OS/2
programming world.

Here are the main points and the reply:

1) There aren't enough Macintoshes out there to make it worthwhile to
support or port games for.

Actually, according to industry stats that I have read, while the
Macintosh may only have 1/10 of the installed base (some claim that it
actually has 1/7 of the *functional* installed base as a Mac Plus from
1985 can run System 6 and virtually every business "productivity" app
out there at usable speeds), the total software revenues from
Macintosh software is about 1/3-1/5 that of the DOS/WIndows revenues.
This is said to be because of the ease-of-use factor that allows the
average Macintosh owner to be far more productive than the average
DOS/Windows user.

In addition, Dr. Dobbs Journal has reported that multi-media houses
that support both DOS/WIndows *and* Macintosh, find that their
customer-support costs for the Mac are far, far lower than they are
for the other platform, due to the plug-and-play nature of SCSI CD-ROM
drives on the Mac side, and the consistent hardware/software that is
the rule with the Apple-made Macintosh (clones may change this but
maybe not).

2) Macintoshes are not as backwards compatible as the various generation
clones are -especially when dealing with graphics.

While there is a certain truth to this (the B&W-only Macs can't do color,
in general), the Macintosh video standard has been at least 256 colors
since 1986/7, and has been 32-bit (16 million color) since shortly
thereafter. *EVERY* color-capable Macintosh has available the options for
B&@, 4-color, 16-color, 256 color, 32,000 color, and 16 million color,
depending on the built-in video/plug-and-play video.

And, since it is plug and play, an application such as a game can read
what is available on which video monitor (you can have up to 6 using
NuBus cards) and which resolution (dots per inch) and which color mode (1
bit through 24-bit) is available on each monitor and either use the
built-in graphics of the Mac or use customized, write-to-each-screen
graphics, to implement whatever drawing that you want.

As an example of how backwards compatible Macintoshes programs (such as
games) can be, there is a simple, shareware arcade game written almost
completely in 68000 assembly language, that draws directly to the
video-memory, which runs just fine in the original color Mac ii, as well
as on the PowerMacintosh 8100/110.

One can even use the exceedingly accurate Time Manager calls in the API
to time whether your custom blitter is faster or Apple's blitter
(CopyBits) and decide which to use, depending on whether accelerator
video cards are installed or not.


3) Video modes are more standardized on the PC's than on Macs.


Aside from the black & white only Macs (and even the SE/30 has the
capability to handle color), ALL Macs use the same video modes. EVERY
SINGLE ONE OF THE COLOR-CAPABLE MACS EVER MADE USES THE SAME VIDEO MODES,
REGARDLESS OF WHAT KIND OF VIDEO CARD IS INSTALLED.

Period. <sheesh>

The modes are: 1 bit, 2-bit, 4-bit, 8-bit, 15-bit, 32-bit colors
available in a program-accessible combination on each of the 6 monitors
that a Mac can handle. The total number of pixels that a monitor or
combination of monitors can have is 32,000 pixels horizontally and 32,000
pixels vertically. The user can use the control panels to arrange the
monitors into a virtual screen that is of any shape at all, as long as
every monitor is touching at least one other monitor at at least one
point (you can arrange them in a diagonal with each monitor touching the
upper right-hand cornder of the monitor below it, for instance). A
standard (even Microsoft Word/Excel) business app can then use the
built-in graphics to stretch a window to cover all the screens, although
parts of the window may not show if the arrangement of the monitors isn't
rectangular.

A game programmer can elect to use custom-blitters to each monitor, or to
use the built-in CopyBits blitter (similar to, but FAR, FAR, FAR, FAR
more sophisticated than, WinG). As I said earlier, you can use
20-microsecond-resolution timeing to determine various issues, like
whether to use standard API calls (in the case of an accelerator video
card) or your own custom-blitters.

A programmer can elect to use only one monitor, or to request which
monitor should be used for what, or determine what the programmer thinks
would be best.

Programmers can also change the number of colors available, on-the-fly,
while the program is running, in order to get the fastest possible
performance.

4) PC's have a more standard sound I/O.

Of all of the misconceptions stated, this is probably the least forgivable:


The original Macintosh, presented to the public in 1984, had 8-bit mono
sound that was capable of generating text-to-speech via software. This
has improved over the years, but the API has been backwards compatible
with almost every Mac (1985 on) ever built. With the advent of Sound
Manager 3.0, EVERY Macintosh since 1985 can play 8-bit and 16-bit sounds,
even if only an 8-bit sound chip is available, as the OS's sound software
will convert on-the-fly, when needed. As well, Sound Manager 3.0 allows
the addition of high-end sound cards that can (and do) make use of the
same API as the built-in sound, so that your little 8-bit sound chip on
the Mac ii can be transparently replaced by the most expensive MIDI card
that money can buy, and most games will then use the MIDI card to produce
the sound fx of the game.

With the advent of QuickTime 2.0, software (or hardware) generated MIDI
instruments are available to all 1985 and beyond Macs (95% of them, in
other words), which will allow games and multi-media presentations to use
MIDI in a standardized way. Look at the size of the Music file for the
game Marathon for an idea of what this means: 250K of MIDI sound tracks
results in nearly continuos music for 27 levels. On the other hand, the
various beeps, grunts and gun-fire sounds of the game take up ~ 1 megabyte.


5) the installed base of the Mac just doesn't make it worthwhile to
develop for games. Stuff about needing to have "emulation modes" for
PowerMacs, etc.


Gads. 85% of the operating system on a PowerMac is emulated using a 68020
emulator, and you worry about emulation modes being needed? Most new
games and business apps are "fat" -that is, they contain complete 680x0
code for older Macs and complete PowerPC code for PowerMacs. The
operating system uses the appropriate code at run-time. This holds true,
even when running a "fat" program on a Mac Plus under System 6 that was
built 10 years ago. If, by accident, you insert a PowerPC-only
application in that Mac Plus, programmers know to have a tiny 68K
application "embedded" in the PowerPC program that will run a special
message saying "PowerPC-only, sorry."

And as for the installed-base comment, Marathon runs on virtually all
color-capable Macs, save the very slowest and provides numerous options
for optimization to allow it to run at playable speeds on those that it
will run on. On the slowest Macs, it requires much crippling, but on the
fastest of the PowerMacs, it can do texturemapping with 16 million colors
for the shading.

6) The rest of the article is just blathering with no knowledge of the
subject, IMHO.

 Michael Lewchuk ([e-mail])
wrote:

:I guess developers consider one aspect: "how much money will I make if I
:develop game X for platform Y?", or "Is it profitable to write for or port
:to platform Y given game X on machine Z?".

:As far as I can tell, the difference between Mac and PC platforms is that
:PCs are designed to be backwards compatible.  I don't know if Macs are, but
:with the differences in graphics that I've seen I can't see how they could be
:easily compatible, particularly for graphics-intensive games.

:So what we have is the difference between all the 386s, 486s, and 586s sold
:(if it comes with a slowdown feature if it's realtime) and all of the Apples
:you can get one game to run on.  PCs all have relatively standard video modes
:sound cards, and such, so if you can get a bunch of drivers working for these,
: you've got it made.

:So, to develop something for Apples, you must recover your costs from a bunch
:of computers which can run your software, however restrictive a group this is.
:With PCs, there is such a HUGE market, particularly if you think back to the
:now obsolete 386s (or even sillier, the 286s) that it is likely your loss, if
:any, will be cushioned by the sheer number of consumers, at least some of which
:will buy your product.  To make fruit, er, Apples, more attractive for
:software developers, come up with a relatively standard instruction set and
:graphics modes, or emulation programs (eg. turn your PowerPC into a Mac Plus).

:It's not that it's not profitable to make something for Mac users.  It may
:or may not be.  It's just that it's likely to be far more profitable to do
:it for PCs because of the simple fact that you can develop for 50% of the PC
:users much more easily than 50% of Apple users.  The market develops with
:shares according to the needs of each.  Since there are less Apple users, and
:with more specific needs in terms of CPU, graphics, etc., there will be a
:smaller, more separated market than "wordprocessing for Windows" programs.

:                     Michael Lewchuk
:                     [e-mail]

--
-------------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
-------------------------------------------------------------------------------